Subject: ODAI for SSCP-PU, SSCP-LU, and Dependent LU-LU sessions

From: "Tom Moore (8-444-9932)" <[email-masked]>
Date: Tue, 29 Mar 94 16:37:11 EST

The inclusion of ODAI in the "LFSID Assignments" table was not intended
 to add a new restriction to APPN, but simply to include information
 in the ASM chapter that could otherwise only be found in "SNA Format
 and Protocol Reference Manual" (SC30-3112-2) and that was referred
 to elsewhere in the APPN Architecture Reference, as follows:

 o The opening section of SC30-3422-1 explicitly points out that
   the T2.1-BF protocols for dependent flows are identical to those
   used for T2.0-BF protocols and differ from those for the independent
   flows, which are the same as the T2.1-T2.1 protocols.

 o The "About This Book" section (p.v) of SC30-3422-2 points out these
   same distinctions.

 o The point was made explicitly on p. 6-6 of SC30-3422-3 for SSCP-PU
   sessions, but obscured for the other dependent sessions -- hence,
   one reason for the amendment to Figure 6-1 discussed at the AIW.

 If you look at the SC30-3112-2 reference, you'll see that the ODAI bit
 is reserved for T2.0-BF flows in both directions, and thus always
 set to 0.

 The intention for making the T2.1-BF flows identical to the T2.0-BF
 flows in the dependent case was to enable products to share existing
 code, and indeed products do this.

 We've polled AS/400, COMMGR, and 3174 to determine what would happen
 if they received an ACTPU, an ACTLU, or a BIND (for a dependent LU-LU
 session) where the TH specified ODAI=1.  For ACTPU, each product will
 accept the request, but return ODAI=0 in the RSP(ACTPU), the
 architecturally correct response.  Preliminary feedback indicates
 the case is more complex for ACTLU and BIND:  it appears that two
 of the products polled check the reserved ODAI bit in these cases,
 and choke if it is not set to 0.

 So, the InSession BF node deviates from the architecture when it is
 configured as a secondary link station and attempts to use the ODAI
 bit for dependent flows, since in this case it is setting the bit
 to 1, which is not allowed for a reserved bit.  Of course, the
 deviation will not be detected if the BF node is configured as a
 primary link station.

 Our preliminary analysis indicates that the BF-BF context does not
 exist for IBM products.  The architecture was never defined to
 accommodate such usage.  It is possible that we could consider an
 extension that would allow the ODAI bit to have meaning for dependent
 flows if both partners have BF capability and request ACTPU in their
 XIDs.  Today, only an InSession-to-InSession connection (with facing
 BFs, each requesting ACTPU) seems to need such an extension.  For the
 extension to work, each node's NOF could indicate the partner's BF
 capability when defining the adjacent node.  Alternatively, we could
 also consider defining a new XID bit to carry this information.  An
 extension along these lines would migrate well in its accommodation
 of existing products.

 --Tom Moore and Gary Schultz

---

From: [email-masked] (Dave Finnie)
Date: Wed, 30 Mar 94 13:05:48 EST

Tom,

Thanks for your response.

>   flows, which are the same as the T2.1-T2.1 protocols.

Yes, but this is somewhat cryptic when seen in conjunction with 
SNA formats (GA27-3136-12) p3-2. My interpretation of the above
paragraph is that the "flows" are the same - i.e. ACTPU, ACTLU, etc.
In formats, however, the description of the ODAI bit in the FID2 TH
specifically includes use between T2.1 & BF nodes, and does *not*
indicate that there is a difference here between dependent and
independent flows. In addition, just under the quoted paragraph is
a referral to session addressing in the ASM chapter, which again,
did not draw any attention to ODAI being reserved for these flows
(until the -3 revision).

> and choke if it is not set to 0.

Your information is slightly incorrect. I have tested against AS/400, and
agree with you there. However, COMMGR definitely echos ODAI on ACTPU
and ACTLU response, even if it is set to 1. COMMGR was one of the first
implementations against which we tested our SSCP support, and hence this
reinforced my interpretation of the NT2.1 referrence. I cannot comment
on the 3174 since we have not tested against it as a NT 2.0.

> extension along these lines would migrate well in its accommodation

A VTAM<->VTAM connection would have the BF-BF requirement (using NT 2.1
links) if it weren't for SSE. Since that interface is not available to
us, we are forced to use the BF-BF option for propagating logons in
both directions.

I understand that this whole topic has become a matter of interpretation
of the NT 2.1 referrence. As you have made clear, my interpretation was
incorrect, but I believe conflicting and incomplete documentation led 
to that problem.

I don't believe it is appropriate for the architecture to be "extended"
merely for our sake. Our node is capable of detecting if the ALS is also
a copy of our node implementation. I will use this ability to gain the 
functionality we require. If the ALS is not a copy of our node 
implementation, then we will assume that ODAI is reserved.

I believe there is still something that needs to be clarified in the
architecture: If ODAI is reserved for dependent LU flows, does that
mean that the node requesting ACTPU can only be secondary on the link ?
If not, then the ODAI value will operate differently for these
dependent LU flows than for independent (because it is reserved). If
that is the case, then what happens if both link stations request
ACTPU ? Does the secondary LS win and get the ACTPU ? Or is it 
defined via configuration ? If both LSs attempt to send ACTPU, then
neither will succeed, because there will be an addressing clash. While
you might think it unlikely that 2 BFs will meet, the architecture
should resolve this case (it already handles all other clashing cases
that I can think of).

Dave